[レポート]Security-JAWS [AWS Security Roadshow Japan 2020] 特別拡大版に参加しました。#secjaws #secjawsroadshow #jawsug #セキュリティは野菜

AWS Security Roadshow Japan 2020 直後に開催された Security-JAWS 特別拡大版のレポートです。

#JAWS-UG

#Security-JAWS

#レポート

#AWS

#セキュリティ

平野文雄

2020.10.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。 HIRANO@おんせん県おおいたです。

10/28に開催された AWS Security Roadshow Japan 2020 の直後に開催されたSecurity-JAWS 特別拡大版に参加しましたので、レポートします。

AWS Security Roadshow Japan 2020 関連の資料

Security Roadshow って何？という方向け。

AWS Security Roadshow Japan 2020 公式ページ

しまった！参加できなかった！！という方向け。

Developers.IO AWS Security Roadshow Japan 2020

Security-JAWS とは

Session1: AWS Security & Compliance エキスパートトーク

AWS高橋さん、AWS高野さん、AWS松本さんによるRoadshowの振り返りトーク

基調講演

AWSはゼロトラストをどのようにとらえているの？
- バイナリーディシジョンではだめ、ネットワーク境界とアイデンティティ制御は両方大切
- AWSのサービスでこれらの制御ができる
- お客様「AWSでゼロトラストやりたい」=>真の課題を聞くようにしている
- ゼロトラストはサービスでもなく、VPNやめることでもない。課題の掘り下げ大切。
COVID-19におけるアマゾンの中の人との働き方
- 元々オフィスに行かなくてもこまらなかった。Work From Homeできていた。
- ソーシャルエンジニアリングへの対応Tipsの共有。
Cloud Audit Academyって何？
- 監査の方法をプログラム化
- 監査部門の方々が、どのようにクラウドを監査すればよいのか、を伝える
- 当局の方の不安を払拭してきた次のステップ
- AWSへの信頼感を増してもらう
- 海外では監査人向けのワークショプを実施 -> Cloud Audit Academy
- ここ数年で監査法人、ISOの審査員がAWS学んでいるが、トレーニングコースがマッチしていない
- 日本でも展開したいので、フィードバックください
セキュリティは野菜
- 「パッチマネージメントはセキュリティの専門家にとって頭が痛い問題」を「野菜みたいなものだ」と表現
- アメリカ人は一般的に野菜があまり好きではないので、こんな表現になったのでは
- 自分から進んでパッチマネージメントをやりたくない、というニュアンス
- 自分の健康のためには野菜を摂らないといけない（手数かかるけど）
- セキュリティも体もヘルシーであり続けるために、不断の努力が必要
- 「セキュリティは野菜」が流行ってくれると嬉しい

パネルディスカッション

ゼロトラストに関して、ツールを導入するものではなく、考え方
組織が考え方を身に付けてほしい
ゼロトラストの考え方は、クラウドの導入の後押しになる

お客様セッション

住信SBIネット銀行さま
- AIベースの与信サービスの他社への提供
- これまで金融機関のネットワーキングの定石は専用線
- 設置までの期間、コスト、セキュリティ、可用性を考えてPrivateLinkを採用
- 1:Nでのサービス提供で優れている
Sansanさま
- Session2で開発した人が詳しく説明します

AWSコンプライアンス・プログラムの紹介

金融機関のトレンド->クラウドそのもの
当局の新しいITの取り組み(クラウド/AI/データ分析/RPA)の流れから
EKYC オンライン本人確認、注目されていて重要。当局のデジタル化推進のテーマの１つ。
FISCの安全対策基準のAWSの取り組み->反響が大きい。AWSが積極的に取り組みたい領域。

コンプライアンスの観点から見るクラウド設計

CloudEndure、Marketplaceから調達できるDR対策サービス
OSSのセルフアセスメントツールの紹介
AWS社員がビルダーとしてOSSを開発するケースが増えている。
ハードウェアの破砕証明に替わる暗号化消去。それのサンプルコードを公開。

Session2: オープンソースで公開した「SIEM on Amazon Elasticsearch Service」の紹介

10/23にオープンソースで公開 https://github.com/aws-samples/siem-on-amazon-elasticsearch
SIEMはSecurity Information and Event Management
あらゆるデータを収集一元管理、相関分析により脅威検出とインシデントレスポンスとサポートするソリューション
NISTサーバーセキュリティフレームワークの「調査」のステップをを効率的に実施する
調査の目的
- トリアージ
- 根本原因の特定
- 被害規模や漏洩情報の特定
迅速に調査できれば、対応完了までの時間を短縮して被害を最小化できる
ログ調査の課題
- 脅威アラート生成が複数に分散すると管理が難しい
- 調査対象が広範囲で多数のログ収集分析に時間を要する
Amazon ElasticSearch Service
- Kibana+Elasticsearch のマネージドサービス
- UltraWarm 新しいストレージ層：ログを扱うのにメリット
- 古いログをUltraWarmに保存して最大90%コスト削減
SIEM on Amazon Elasticsearch Service
- セキュリティ監視をするためのスクリプトやダッシュボードのサンプル
- オープンソースで公開
- 日本のSecurity SAが開発
- 特徴
- マネージドサービスとサーバレスのみで構成
- CloudFormation/CDKによるデプロイ。約20分で完了。
- クラウドサービスを利用した分だけの従量課金
- AWSサービス専用の正規化、ダッシュボード
- マルチアカウント、マルチリージョン対応
- 構成図
- ダッシュボード
- ログの正規化が必要。インシデント対応は緊急、正規化しておけば簡単に早く分析できる。
- 現在対応しているログ
- OSS開発参加のお誘い

参考：AWSの各種ログを可視化するOSSのSIEMソリューション「SIEM on Amazon ES」がAWSから公開されたのでCloudTrailログを可視化してみた

Session3: パネルディスカッション「セキュリティログ分析・運用を上手いことやるには」 AWS 松本さん、AWS中島さん、Security-JAWSメンバー

① SIEMの活用法について

AWSのアーキテクチャいろんなパターンがある。それらに対応しているの？
- RDS/コンテナのログは現在は対応していないが、対応しようとしている。フィードバック最優先なので、フィードバックしてください。
とりあえずはCloudTrailでやってみた。AWSのセキュリティとしては、まずはCloudTrailで不審なアクティビティがないか確認する。SIEMを使うと、CloudTrailのダッシュボードでの可視化が、これからAWSのセキュリティを始める人が手始めに見るのにちょうど良い。
CloudTrailダッシュボード、こういうとこ見てもらいとう意図があれば知りたい
- 自分が見たいと思ったのを見れるようにしたかった。
- SIEMはハードルが高いので、簡単に導入運用できるようにしたい。
- AWSはフォーマットが決まっているので、自分が作れば他の人もすぐに使えると思った。
- 自分が見たいなと思ってたことを、見てもらえて（評価してもらって）嬉しい。
初めて利用した人が、見た方がいいよというところがまとまってるのがよかった。
会社によって、見たいログ、相関分析の内容は異なる。自分たちでルールを書きたい。ルール作成周りは整備されている？
- 皆さんがよく使うものは、(ルールではなく)実装した方が良いと思う。
- 特定分野で特定のお客様しか使わないものは、お客様自身で作る方がよい。
ルールはどのくらい実装されている？
- ルールはまだゼロ。
- 分析できる基盤の開発を優先してきた。「簡単に分析できる」ことを注力している。
SIEMは定点観測的な使い方と、探したいものをアドホックに調べるというのができる
組織によってログの特徴は違う。結局は自分でクエリを書かないといけないと思う。
ElasticSearchのクエリ言語、スキーマの学習コストどう？
- 少し勉強が必要
- ElasticSearchの書き方とSQLを使う方法があり、後者は敷居が低い。
- Elastic Common Schemaに則っている、基本がわかれば使えるようになる。
Kibanaの中身見れる？設定変えれらる？
- 許可されている範囲で設定できる
- ソースコード変更などはできない（AWSがマネージドしているので）
ランニングコストは？特にログこのくらいなら、このくらいのコスト的な。
- ログ量とコストの関連はまだ出せていない
- 検証用（アカウント４つ、様々なリージョン）で５万円程度。ただ使い方による。
AWSのログって、一箇所でまとめてみるの結構大変なので、非常に良いソリューション
GuardDutyのペストプラクティスは、全リージョンで有効にする。費用はほとんどかからないが、全リージョンのログをチェックするのは手間。これを集約してSIEMで確認する使い方オススメ。
GuardDuty即有効にしてもらいましょう。
GuardDuty有効にしてないアカウントとかないやろーw
GuardDutyはコンソール上で90日しかログを見れない　- SIEM入れるとその期間を超えても過去分みれる。地味に嬉しい。

② コンプライアンスモニタリングとSOCモニタリングの距離について

最近はContinuous AuditingやCompliance as Codeという言葉があるので、この話題に触れる
SIEMのツールを使ってコンプライアンス側のモニタリングもやっていく必要があるのか？
- トラディショナルなSOCサービスを提供しているベンダーさん、組織の中のCSIRTがSOC持っているケースでは、彼らはもともとコンプライアンスモニタリング的なもの
- クラウドを使ってCompliance as CodeやContinuous Auditingができるようになってきて、監査人が年に一回チェックしてきたものから、常に見られうようになった
- 常に見れる道具があるが、誰がどう使うのか
- 経営レベルで考えると、CISOは抽象化された情報をどうやって集めて、意思決定するのか
- 結構難しい問題。皆さんの意見聞きたい。
コンプライアンスとSOCは車の両輪のようなもの
コンプライアンスは、準拠すべき規制法律をどの程度守れているか上流から下流まで一貫して見続ける、長いスパンのもの。
途中から実装に入ってくると、Compliance as Codeとなり、実装レベルでレポーティングされる、というのがCISOがやりたいこと
SOCは、ネットワークのモニタリング、日々の脅威監視、など短い単位で繰り返しやること。
侵害の発生事項への対応の積み重ね、対応の時間をまとめてCISOにレポートする
CISOは、コンプライアンスはこれだけやってて、現場ではこうなっている、というのを説明できる。
AWSは可視化をしやすい。SecurityHUB
見るべき監査ポイントは見えてくる
SOCオペレータの人たち、監査のレポート見れたら見た方がよい
24/265で行うSOC業務とは切り離すところにある
もし、コンプライアンス的な変更により問題が発生したとき、相関して見れれば嬉しい
それをルールで実装するのは難しいだろうなぁ
しばらくは距離はある
SOCの人たちがそういうところを見るようになる時代はそう遠くはない
ゼロトラスト、ツールではなく文化
SIEMを使いこなすために、自分たちはどう育っていくのか
見つめ直すいい機会
Compliance as Codeできている会社、登壇してほしい

③ OSSとしてのセキュリティ製品ってどう進展すれば良い？

非破壊型スキャナVulsはGitHubで公開、かなり話題になった
SIEMもOSSとして広がって欲しい。いい手段あるのかな。
開発したなかじまさん、どうなってほしい？
- 日本が中心となっている製品として世界の人に使って欲しい
- 日本のみんなに協力/フィードバックしてほしい
- みんなのアイデアほしい
いいアイデアあります？
- Vuls流行り始めた時、イベントが多かった。そういうのをやったどう？。
- SIEM Meets Upとかやっちゃたら
- ログは組織において生き物なので、触る機会を増やした方が良い。
- 実際は触ってなくて、選定をやってるのが現状
- まずは構築して触ってみるのが大切
- もくもく会、ワークショップなど
- SIEMの活用イメージがとても重要
- まずは手動で体験してもらう。自動化とかはその先

まとめ

セキュリティ関係の皆さんはもちろん、普段セキュリティに携わっていない人にとっても刺激のある勉強会だったのではないかなと思いました。 YouTubeで公開されていますので、参加できなかったは、ぜひごらんください。

感想

以前、主要都市を回って開催していたAWS Cloud Roadshowでは、セッション終了後にJAWS-UGが開催されてました。AWSおじさんとしては、その頃を懐かしく思い出す勉強会でした。 AWSの方が肩の力を抜いてユーザとトーク、本編では聞けない話を聴ける貴重な場でした。他の分野でもこのようは連携があると嬉しいです。